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TIME TRANSFER USING NAVSTAR GPS 

A. J. Van Dierendonck, Q. D. Hua, J. R. McLean, A. R. Denz 
Stanford Telecommunications, Inc. (STI), Sunnyvale, CA 94086 


ABSTRACT 

The NAVSTAR Global Positioning System (GPS) allows 
extremely accurate and global determination of time, as 
well as position and velocity. An STI Time Transfer Unit 
(TTU) developed for the U.S. Naval Observatory (USNO) has 
consistently demonstrated the transfer of time with accu¬ 
racies much better than 100 nanoseconds. A new STI Time 
Transfer System (TTS), the TIS 502, is currently in devel¬ 
opment and will be available on the market by the end of 
1981. The TTS 502 will be a relatively compact micropro¬ 
cessor-based system with a variety of options that will 
meet each individual's requirements, and will have the 
same performance as the USNO system. This paper summa¬ 
rizes the time transfer performance of that USNO system 
and presents the details of the new system. 

INTRODUCTION AND SUMMARY 

The NAVSTAR GPS is currently operating in its Concept Validation Pnnse 
(Phase I), while the operational system is under development. Rather 
than being repetitive on the description of the system, which has been 
described in numerous papers over the last 6 years, let it suffice to 
refer to a few of these papers in References 1 through 3. The impor¬ 
tant factor to note here, however, is that even though the system is 
not fully operational, it already provides the best overall time trans¬ 
fer capabilities in existence. Time transfer, using a Time Transfer 
Unit (TTU) designed and built for the U.S. Naval Observatory (USNO) by 
STI, has been demonstrated to be consistently better than 50 nanoseconds 
when done so with GPS satellites with good clocks. 

Ultimately, GPS will allow continuous global determination of time when 
the complement of satellites in the system provides the appropriate 
coverage. (Only one satellite in view is required for time transfer.) 
At present, global determination is possible, but not continuously. 
Currently, the GPS program plan is to have an 18 satellite constella¬ 
tion 4 , which would provide global satellite visibility of 4-8 satel¬ 
lites above 5° elevation (7 satellites 28.7% of the time). 5 The origi¬ 
nal planned constellation of 24 satellites would have provided visibil¬ 
ity of 6-11 satellites above 5° elevation. A possible near-term con¬ 
stellation of six satellites will provide one satellite time transfer 
coverage ranging from approximately 16.5 to 20 hours per day, depending 
upon location. As it turns out, one of the worst time coverages is the 
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continental United States (and the Indian Ocean) because the constella¬ 
tion was designed to provide a clustering of satellites for testing at 
Yuma, Arizona. 5 Examples of satellite coverage for those six satel¬ 
lites are presented in Figure 1. 

The Time Transfer Systems, both old and new, operate on only the GPS 
LI C/A (Clear/Acquisition) code at 1575.42 MHz. They do not operate on 
the L2 frequency (1227.60 MHz) because the C/A code will usually not be 
available on that frequency. The reasons for operating only on the C/A 
code are for simplicity and because, in the future, the P-code will not 
be available to all users. It will be obvious from later discussions 
that operating on the P-code would only improve the time transfer 
accuracy by about 30-35 nanoseconds (one sigma) when operating with 
large ionospheric propogation delays, to very little improvement when 
the delays are small. For most applications, this improved accuracy is 
not required, and for some users that need it, special purpose P-code 
time transfer systems can be developed. 

The Time Transfer Systems also operate only from known surveyed (and 
stationary) locations. In future systems, position determination with 
limited motion is anticipated as an option. Position determination 
does degrade the time transfer accuracy because of Geometric Dilution 
of Precision (GDOP) and Time Dilution of Precision (TDOP) effects (see 
Reference 4 for definitions of GDOP and TDOP). 

The USNO TTU is described in detail in References 7 and 8. This unit 
was delivered to the USNO late in 1979 and has been operating since 
mid-1980 very well. 9 A summary of results obtained from this unit will 
be presented later in this paper. It has been instrumental in the 
determination of the long-term performance of the GPS frequency stan¬ 
dards in orbit, as well as the performance of GPS time. 

The USNO TTU, because it was the first Time Transfer System built, is a 
large and not so portable unit. Because of that, STI has developed a 
new TTS, the TTS 502, that has similar performance characteristics, but 
is relatively small, even to the point of being portable (a near future 
option). The unit is shown in Figure 2. Details of this new system 
are presented later in this paper. 

Also presented in this paper are the techniques for accomplishing the 
time transfer, a time transfer error analysis, a description of various 
applications of the TTS and some future considerations for the use of 
GPS for time transfer. 

TIME TRANSFER TECHNIQUE 

For users with known locations, only one satellite signal is required 
for time transfer purposes. The time transfer technique employed is 
illustrated in Figure 3 which shows the timing relationships between 
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the system (GPS) time, satellite time, and the user's time when an 

epoch transmitted from the satellite (at GPS time arrives at 

GPS 

the user's location (at GPS time T A ). Time transfer is accomplished 
M U 

by computing the user clock error, AT^ , with respect to system time, 

when an epoch is received. GPS satellites transmit continuous signals 
with readily identified subframe epochs every six seconds. The trans¬ 
mission time, T- t SV , is determined by an on-board atomic standard which 

SV 

will, in general, differ by some amount, AT^ from system time. 

When the epoch arrives at the station, the transit time is measured as 
observed by the user. This measurement, called pseudorange (PR), is, 
in essence, the time difference between the user time at epoch arrival 

T^, and the satellite time at epoch transmission, Ty SV , i.e., 

PR - T A U - J T SV (1) 


In terms of system time, the pseudorange can be expressed as 


T GPS T GPS 

'a " ! t 


v v - 


u 


( 2 ) 

GPS GPS 

The term T^ - Ty is the "true" transit time (with respect to 

system time) representing the true time range, R, between the satellite 
and the station except for a propagation delay t: 


’1 

The user clock error is readily obtained from (2) and (3) as 


I . 


SV 


(3) 


(4) 


The propagation delay includes the ionospheric and tropospheric propa¬ 
gation time delays and a receiver equipment bias. 

A raw time transfer is performed every six seconds at the reception of 
the satellite signal epoch (subframe epoch) by the following 
procedure: 

o Deriving satellite (epoch) transmission time,.®, from the 
Z-count contained in the broadcast data subframe (inferred 
after initial synchronization). 
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o Computing satellite clock error, AT t SV , and system transmis- 
GPS 

sion time, T^ , using clock correction parameters contained 
in the data frame. 

o Computing satellite position at system time T T GP $ using the 
satellite's ephemeris contained in the data frame. 

o With the known user location, estimating the propagation delay 
x using (1) ionospheric correction parameters contained in the 
data frame, (2) a simple tropospheric correction model, and 
(3) receiver equipment bias calibration data provided by the 
user during system initialization. 


o Computing the satel1ite-to-station range R, taking into account 
the effect of earth rotation during signal propagation. 


o Collecting a pseudorange measurement, PR, when the epoch 
arrives, and finally, computing the user clock time error 

AT^ according to equation (4). 


These raw user clock time errors are then collected in a rotating buf¬ 
fer so that they can be smoothed to reduce the effect of the receiver 
noise and quantization errors. The smoothing is accomplished by 
applying a least squares fit on the values in the buffer. This 
smoothed error is then subtracted from the time of the epoch arrival 
to provide the GPS time of arrival 


(5) 


where AT^ is the smoothed user clock time error evaluated at user 

time T. u . However, the time transfer is accomplished by providing 

U 

the user with a time pulse that is either coincident with T^ , along 
with the correction, or with a time pulse that has been corrected with 

the past best estimate of AT. G , and thus corrected to I a GPS or T a G ^ G . 

a ft htc 

The corrected pulse is an option of the TTS. To correct to T^ , the 

epoch time of arrival in Universal Coordinated Time (UTC), a known 
difference between UTC and GPS time is applied. This known differ¬ 
ence is presently supplied by the user. In the future it will be 
supplied in the GPS Navigation Message 8 . 


THE TTS 502 


A block diagram of the TTS 502 is shown in Figure 4. It is comprised 
of an STI Time Transfer Receiver Model 5026, an Omni byte Motorola-based 
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MC68000 microcomputer and software, antenna, preamplifier and a dis¬ 
play station. Also, options to the basic TTS-502 are illustrated. 
These options are: 

o 001 Precision internal 5 MHz crystal oscillator 

o 002 1 pps (pulse-per-second) output corrected to GPS or UTC 
time 

o 003 RS-232 interface for data output to external peripherals 

o 004 GPIB interface for data output to external peripherals 

o 005 Desk Top Cabinet Enclosure (not shown) 

Other options will be added in the future and will be based on future 
user requirements. For example, for portability, an option for a 
portable chassis and a portable display and control terminal will be 
offered. 

Timing Sources 

The TTS's flexible relationship to external or internal frequency 
standards, oscillators, or digital clocks is illustrated in Figure 5, 
resulting in 3 time-source operating modes. 

The TTS-502 can be controlled with a 3-position switch on the rear 
panel to operate in one of the following three modes: 

Mode 1: Internal 5 MHz and Internal 1 pps Mode 

(Internal 5 MHz with Option 001 only) 

In this mode, an external 1 pps signal is not required. With Option 
001, the TTS-502 includes a precision 5 MHz quartz crystal oscillator 
generating an internal 5 MHz signal from which all the required fre¬ 
quency references and timing pulses are generated when operating in 
Mode 1. The GPS time transfer is made with respect to an internally 
derived 1 pps signal. A TTS-502 with Option 001 can also operate in 
Mode 2 or Mode 3. 

Mode 2: External 5 MHz and Internal 1 pps Mode 

In this mode, a user-supplied external 5 MHz signal is used to derive 
all of the required frequencies and timing pulses. The TTS-502 uses 
the 5 MHz input signal to internally derive a 1 pps signal for refer¬ 
encing the GPS time transfer. 
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Mode 3: External 5 MHz and External 1 pps Mode 


In this mode, a user-supplied external 5 MHz signal and a user-supplied 
1 pps are input to the TTS-502. The GPS time transfer is made with 
respect to the externally supplied 1 pps signal. 

In all of the above operating modes, the 5 MHz signal is passed through 
and available as an output at the rear panel. The 1 pps used to refer¬ 
ence the GPS time transfer (internally derived in Modes 1 and 2, exter¬ 
nally provided in Mode 3) is also available at the rear panel with the 
basic system. With Option .002, this pulse is time-shifted to corre¬ 
spond to GPS or UTC time. 


The preamplifier and antenna, which are included in the TTS-502 system, 
are off-the-shelf items. The preamplifier is an Avantek AM1664 modi¬ 
fied to accept power via the RF cable to the receiver and high power 
input protection (Avantek M1664N103). This preamplifier is tuned to 
the LI frequency with a minimum of 50 dB gain, and a noise figure of 
3 dB and a bandwidth of 10 MHz. This will insure a receiver system 
noise figure of less than 4 dB, even for installations with very long 
preamplifier-to-receiver cable lengths. Its size is approximately 
8 inches by 3 inches by 2 inches, including connectors. 


The antenna is an omni-directional antenna. It is right-hand circular 
polarized and has greater than -2 dBIC gain above 10° elevation angle 
and greater than -3 dBIC gain above 5° elevation angle with hemispher¬ 
ical coverage (measured on a ground plane). 


Receiver/Processor 


A block diagram of the Receiver/Processor subsystem of the TTS-502 is 
shown in Figure 6. This subsystem is the portion of the TTS that is 
housed in the 8-3/4-inch chassis shown in Figure 2 (which includes the 
Option 001 oscillator, if provided). The receiver has its baseband 
processing and control resident in firmware in a microprocessor. The 
receiver hardware consists of a downconverter, correlator, code gener¬ 
ator, code and carrier NCO's (Number Controlled Oscillators), fre¬ 
quency synthesizer and timer and a 115 volts, 60 cycle, (both ±10%) 
power supply which also supplies DC power to the preamplifier. The 
receiver operates on the LI, C/A code signals only, and in conjunction 
with the microprocessor, acquires the satellite signals, tracks the 
code and carrier of the acquired signal, demodulates the navigation 
data, performs parity checking on the data, measures pseudorange and 
doppler and provides the data and measurements, upon request, to the 
MC68000 microprocessor. That control will occur at a maximum rate of 
once per second, either as an acquisition command or as a measurement 
request. 
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The receiver accepts the LI C/A RF signal from the preamplifier. Its 
sensitivity is better than 132 dBm (at the preamplifier) and it has a 
dynamic range of greater than 20 dB, with a spurious response greater 
than 60 dB at 130 MHz from the carrier. Its 3 dB IF bandwidth is 25 
MHz. Its pseudorange measurement resolution is 48.9 nanoseconds, which 
in the time transfer algorithms, is smoothable down to a one sigma of 
0.9 nanoseconds. 

The MC68000 microprocessor, in addition to controlling the receiver, 
contains all of the time transfer software (firmware). Its basic duty 
cycle for computing time transfer values is once per six seconds. 
Some of the basic features of this processing are described below. 

Time Transfer Software Processing 

The TTS software package resident in the MC68000 microprocessor is 
written primarily in a FORTRAN language. However, the entire software 
system will be compiled and "burned" into Programmable Read Only Mem¬ 
ories (PROM's) on the microprocessor card. In addition to volatile 
Random Access Memory (RAM) available for processing, nonvolatile RAM is 
used to store initialization parameters to circumvent reentering those 
parameters whenever power is lost or removed and then restored. 

The software routines are designed to perform a variety of functions: 
operator input handling, receiver signal acquisition control, satel¬ 
lite data collection and processing, scheduling and schedule control, 
time transfer algorithm execution, data smoothing, data statistical 
analysis, data display, data output, etc. 

The primary purpose of the software processing is to provide the user 
the flexibility of exercising various modes of operation to suit his 
requirements. Most important, the software processing provides an 
automatic mode of operation in which visible satellites are scheduled 
to be tracked under software control, permitting continuous time 
transfer operation. Once this mode is initiated, no further operator 
intervention is required, and the TTS is operated in a so-called "do 
forever" loop. 

The TTS with its application software processing is designed primarily 
for the automatic controlling of the receiver to track a sequence of 
visible satellites based on a 24-hour tracking schedule, in support of 
continuous time transfer operation. The TTS provides two modes of 
control for setting up this schedule. 

Under the full automatic mode of control, a 24-hour satellite tracking 
schedule is generated internally by the software based on a stored 
almanac and known user location. The criterion used for generating a 
schedule is such that every satellite chosen by the operator will be 
tracked at least once every day. This schedule is automatically 
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revised daily to account for the GPS satellite constellation preces¬ 
sion. To override the full automatic schedule, the user may exercise 
the semi-automatic mode of control in which the user is allowed to set 
up a 24-hour schedule using any criterion he may choose. 

In either mode, once a schedule is set up, it will be maintained by 
the program and, at the beginning of each tracking interval, the 
receiver will be automatically reset with a new satellite identifica¬ 
tion number and initial doppler estimate computed using stored almanac 
data. Since almanac data for all satellites are updated occasionally 
by the GPS Master Control Station, the stored almanac data to be used 
by the system are continuously and automatically refreshed once the 
system is in operation. 

Starting with a new satellite acquisition command, the time transfer 
operation proceeds through three phases of operation. In the first 
phase,the signal acquisition phase, the receiver will acquire and track 
the selected satellite. During this phase, the receiver acquisition 
process is monitored by the program until the signal is successfully 
acquired and subframe synchronization is achieved. In the next phase, 
the initial data acquisition phase, satellite data subframes demodulated 
by the receiver are input and processed every six seconds until a 
complete set of error-free data is collected. Normally, these two 
phases will take much less than one to two minutes, depending upon 
whether time had been previously established. The final phase, time 
transfer solution phase, will last for the rest of the scheduled time. 
This phase consists of a number of time transfer cycles, each cycle 
occuring at 6-second subframe epochs. 

At the beginning of each cycle, the processor inputs a 300-bit data 
subframe, receiver status information, and measured pseudorange and 
doppler from the receiver. Pseudorange and doppler measurements are 
taken every second and combined at the end of six seconds to provide a 
smoothed measurement for the time transfer computations. The receiver 
status information is used for monitoring the receiver performance, 
and for accessing the validity of the measured pseudorange. The pur¬ 
pose of the data subframe is threefold: first, to derive the satel¬ 
lite time of transmission from the subframe Z-count; second, to refresh 
satellite navigation and almanac data; and finally to check if the 
navigation data is being updated by the satellite. If so, a new set 
of satellite ephemeris data will be collected to keep the microproces¬ 
sor data base current. 

The time transfer algorithms are then applied to estimate user clock 
time error, to enter that error into the time offset smoothing process, 
to display data in a variety of forms, based on user's selected options, 
and to output data to the optional output ports. Typical displays 
show the station clock time error, the time of day (in GPS or UTC time), 
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date (in Modified Julian Date Number), age of data, receiver status, 
satellite identification number, and elevation and azimuth angles. 

Besides the two major modes of operation described above, the ITS 
software processing also provides additional modes of operation which 
allow the user to initialize the data base, collect an initial set of 
almanac data, to obtain satellite constellation times of visibility, 
and to exercise the manual mode of control Jtf which a particular 
satellite of interest can be tracked until terminated or until it is 
no longer in view. 

TIME TRANSFER ERROR ANALYSIS 

Various sources of error that could affect the accuracy of the time 
transfer to varying degrees are listed in Table I and are discussed 
below. 

Satellite Group Delay and Clock Errors 

Normally, satellite group delay, which is caused primarily by delays 
in satellite signal paths, are indistinguishable from the satellite's 
clock time offset. Therefore, they are included in the GPS Control 
Segment's estimate of that clock offset. However, that estimate is 
based on dual frequency (LI and L2) measurements of pseudorange, 
absorbing any group delay differential between the LI and L2 signal 
paths within the satellite. This differential has no effect on two- 
frequency users. However, since the TTS has an LI only receiver, that 
differential, multipi ied by a factor of 1.546,is not accounted for in 
the polynomial clock correction terms of the Navigation Message. 11 
However, it is accounted for in the TGD term included in that message. 
The error in that term is affected, however, by the Control Segment's 
ability to measure it through the ionosphere at times of relatively 
small ionospheric delays. However, that error, along with perturba¬ 
tions in the absolute group delay in the satellite, is expected to be 
insignificant compared to the satellite's random clock drift described 
below. Therefore, they can be neglected. 

The satellite clock errors are basically the error in the satellite's 
polynomial clock correction terms of the Navigation Message. That 
error is caused by three sources: the satellite's random clock drift, 
the group delay described above, and the Control Segment's inability 
to estimate and predict the clock drift exactly. These errors are 
very much related, so it makes no sense to try and differentiate them. 
Over a period of time, however, the random clock drift will normally 
dominate if the satellite's clock is reasonably stable. (In other 
words, a clock is one that meets specification - a nonanomalous satel¬ 
lite.) That assumption is made here, since that is the case for all 
but the first two satellites launched. In fact, the most recently 
launched satellites have very stable clocks. 
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Since these clocks do vary in stability, it makes more sense to dis¬ 
cuss the specified stability rather than the actual stability. The 
numbers in Table 1 reflect those specifications 12 ’ 13 . For the Phase 
I satellites, the clock errors were specified for only two hours after 
upload of the satellite, obviously to cover specific testing periods. 
However, since the TTS could be used anywhere, that error budget has 
been extended to 24 hours here, using the clock Allan variance charac¬ 
teristics provided in Appendix III of Reference 13 and the time drift 
models of Reference 14. Since there are two types of frequency stan¬ 
dards operating in the Phase I satellite (Rubidium and Cesium), a 
range is given for the clock error budget of 25.5-108 nanoseconds (one 
sigma) for 24 hours after upload (25.5 for Cesium, 108 for Rubidium). 
These are based on the equations: 

a 2 (t) = 10-20 ( t_t uPL0AD) 

+ 1.44 X 10- 24 (t-t upLOAD ) 2 seconds 2 (6) 

for the Rubidium standard, and 

a 2 (t) - 2.5 X 10" 21 (t-t upL0AD ) 

+ 5.76 X 10- 26 (t-t upL0AD ) 2 seconds 2 (7) 

for the Cesium standard. 

Although the drift of the Rubidium standard causes the TTS error budget 
to exceed the 100 nanoseconds advertised, the standards that are opera¬ 
tional have been performing much better than specified. 

For the operational GPS system, the Operational Control Segment (OCS) 
is simply specified to upload the satellites as often as required to 
maintain the combined clock and ephemeris errors to within 20 nanosec¬ 
onds (6 meters), one sigma. 

The nature of these clock errors are basically bias-like over the 
smoothing interval of the TTS (240 seconds, maximum). 

Satellite Ephemeris Prediction Errors 


These errors are primarily the Control Segment's inability to predict 
the satellite's ephemeris (position versus time) exactly plus any 
perturbations that are unpredictable. These errors, along the line- 
of-sight to the user, are budgeted to be 12 nanoseconds (3.6 meters), 
one sigma for the Phase I system for 24 hours after upload, and are 
combined with the clock errors as described above for the operational 
system. Actually, the errors are somewhat negatively correlated with 
the clock errors and tend to cancel somewhat over short periods of 
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time after upload. Therefore, it makes more sense to combine the error 
budget as it is for the operational system. 

As for the clock errors, the ephemeris errors are basically bias-like 
over the smoothing interval of the TTS. 

Ionospheric/Tropospheric Delays/Multipath Errors 

These errors are obviously independent of each other; however, they are 
worse at low elevation angle tracking and minimized at higher elevation 
angles. The multipath errors can be controlled with good installation 
practices. They can also have a relatively random component that could 
be lumped in with the receiver noise errors. The tropospheric delay is 
corrected with a simple model. 

In any event, the ionospheric delay correction error will usually 
dominate, since the TTS has no capability of measuring pseudorange at 
two frequencies. It must rely on the ionospheric correction model 
provided in the Navigation Message. 10 ’ 16 In fact, under normal situa¬ 
tions, the ionospheric delay correction error will dominate the TTS 
performance. 

Reference 15 treats this correction error in detail. In summary, the 
ionospheric delay error is caused by the integrated electron content 
along the ray path between the satellite and the user. The delay 
effect is dependent on both the character of the ionosphere at the 
zenith and the elevation angle to the satellite. The character at 
zenith is highly dependent on geometric latitude of the user and the 
time of day, and is not very predictable. Figure 7 shows typical 
measurements of ionospheric delay for an L-band signal (near LI) 
received at vertical incidence. 16 The mean ionospheric delay at night¬ 
time is on the order of ten nanoseconds. During the daytime the mean 
delay increases to as high as fifty nanoseconds. At low elevation 
angles the delay can be up to three times the values given above (30- 
150 nanoseconds). Although these delays are partially corrected with 
the Navigation Message models that model will normally be in error by 
about 50 percent of the delay (one sigma). 15 Therefore, as a "ballpark 1 
estimate, it is assumed that the ionospheric delay correction error, 
combined with the tropospheric correction and multipath error, ranges 
between 5-40 nanoseconds (one sigma), depending upon many variables. 
This error is the most important error source of the TTS time transfer 
error. 

Receiver Noise (and Random Multipath) Errors 

Receiver noise is dominated by the thermal noise effects on the per¬ 
formance of the receiver's code loop (neglecting unintentional jamming, 
of course). Since the TTS receiver's code loop is aided by its carrier 
loop, and because pseudorange measurements are relatively infrequent 
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(once per second), its loop bandwidth is quite small, reducing the raw 
measurement receiver noise error to 15.5 nanoseconds, one sigma. 
Smoothing to one-second measurements reduces this error to 6.3 nano¬ 
seconds, one sigma. Also, this error is random in nature; therefore, 
since the ITS software processing smooths the raw time transfer results 
this 6.3 nanoseconds can be further reduced to about 1.0 nanoseconds, 
one sigma (40 sample smoothing). 

Pseudorange Quantization Errors 

The least significant bit of the TTS pseudorange measurements is worth 
48.9 nanoseconds (l/20th of a C/A code chip). This is reduced by the 
square root of 12 to a one sigma value of 14.1 nanoseconds, since it 
is a uniformly distributed error between ±24.4 nanoseconds. (The bias 
is a time error that is part of the receiver's calibration correction, 
primarily because pseudorange, as measured, is always positive). As 
was the case for the receiver noise errors, these quantization errors 
are further reduced in the TTS software processing because they are 
smoothed, reducing the 14.1 nanoseconds down to about 5.8 nanoseconds, 
one sigma for the smoothed 6-second measurement and down to 0.9 
nanoseconds, one sigma, in the time transfer smoothing (40 sample 
smoothing). 

User Location Estimation and Receiver Bias 

The TTS makes use of the user coordinate in the estimation of satel- 
lite-to-user range, and therefore must be known accurately. The error 
budget for this estimation depends on the surveying technique used to 
determine the coordinates. If a GPS Geoceiver is used for the survey, 
the GPS position can be derived quite accurately, to within about 1-2 
meters 17 ’ 18 (^5 nanoseconds). Otherwise, the location error could 
be somewhat larger, and budgeted to be up to about 5 meters U5 nano¬ 
seconds), one sigma. This error is bias-1 ike, and therefore cannot be 
smoothed over the TTS smoothing intervals. 

The TTS receiver bias from the antenna to the input (or output) 1 pps, 
is calibrated prior to TTS delivery. The error and subsequent drift 
in that bias is well within the location error budget given above. Of 
course, any cable length changes require a new bias input. 

Total (RSS) Time Transfer Error Budget 

Table I lists the various individual error budget that makes up the 
total TTS time transfer error budget. The RSS totals are given as 
ranges, consistent with the ranges given for the individual budgets. 
Also, the smoothed error budget is given versus the raw error budget, 
assuming 40 sample smoothing (6 seconds per sample). For the Phase I 
GPS error budget, two totals are given - one for the Rubidium satel¬ 
lite frequency standards and one for the Cesium satellite frequency 
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standards. All budgets are well within the advertised budget of 100 
nanoseconds for the TTS, except for worst case Rubidium frequency 
standard drifts, which to date have not been exhibited. 

USNO TTU RESULTS 

Acceptance Test Results 

The acceptance tests of the USNO Time Transfer Unit were conducted for 
five days in November 1979, as part of the unit acceptance tests. The 
following is an excerpt from a paper by Dr. Kenneth Putkovich 8 , USNO 
representative at the time of the acceptance tests. 

"Initial tests of the time transfer capability of the Time Transfer 
Unit (TTU) were carried out as part of the unit acceptance tests. A 
pair of portable atomic clocks was carried to the MCS (Master Control 
Station) at Vandenberg AFB in California. The ensemble of atomic 
clocks which constitute the GPS master clock were measured against the 
portable clocks with particular attention to the clock serving as 
reference for the Vandenberg Monitor Site. Pertinent system delays in 
the monitor receiver were also measured and verified with site person¬ 
nel. The portable clocks were then transported to the STI facility in 
Sunnyvale, where a series of time transfers were made using the port¬ 
able clocks as reference for the TTU. The clocks were then returned 
to Vandenberg (to establish a baseline for GPS time) and then taken 
back to Sunnyvale for a final series of measurements. The results of 
this initial series of measurements are presented in Figure 4 (Figure 
8 in this paper). As can be seen from the plot, time transfers with 
a precision of better than ±50 nanoseconds were achieved." 

After the portable atomic clocks were shipped back to USNO, additional 
testing was performed, this time using a Cesium standard which was 
calibrated against the atomic clocks. These tests also produced 
similar results. 

Subsequent Testing and GPS Time Performance Monitoring 8 ’ 19 

Subsequent tests performed by the USNO involved the verification of 
GPS Time at the GPS Master Monitor Station via portable clocks and the 
acquisition and tracking of as many passes of the satellites currently 
in operation as possible. These tests resulted in the same level of 
performance as the initial acceptance testing, but revealed what 
appeared to be several discontinuities in GPS Time. An investigation 
showed the cause of these steps to be GPS master clock changes and 
failures in GPS Monitor Stations. Since then, due to a coordinated 
effort between USNO and the GPS program office, an improvement has 
been made as the magnitude and frequency of the discontinuities has 
decreased. More details of GPS Time monitoring are given in Reference 
19, which covers a period of time up through about the end of 1980. 
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The TTU has also been used to monitor the performance of the frequency 
standards in the GPS satellites. Those performances are also pre¬ 
sented in Reference 19 over the same time frame and have also been 
presented in terms of Allan variance numbers in Reference 20. That 
performance is monitored by "backing out" the satellite clock correc¬ 
tion polynomial derived from the GPS Navigation Message 11 , which 
basically "uncorrects" the satellite clock time from GPS Time to the 
time of the satellite's subframe epoch transmission. In a sense, the 
accuracy in this TTS estimate of satellite time is better than that of 
GPS Time because it is not corrupted by the prediction errors in the 
clock correction polynomial, which is evident from results presented 
in Reference 19. However, this estimate is of little value to the 
normal TTS user, unless he is primarily interested in monitoring 
satellite clock performance, with one exception. Since the USNO 
publishes the difference between their Master Clock and each satel¬ 
lite's clock, a user can perform a time transfer to UTC via a satel¬ 
lite clock instead of via GPS Time. The published difference of a 
good satellite clock is more accurately predictable by extrapolation 
than that of GPS Time to the user's time of transfer. However, if the 
user does not extrapolate and uses data common to the USNO after the 
fact, it makes no difference because the clock correction polynomial 
prediction errors cancel. (In fact, in a common view time transfer 
performed while in communication with the USNO, all common errors such 
as satellite clock errors, ephemeris prediction errors, and part of 
the ionospheric delay correction errors cancel, resulting in a more 
accurate time transfer. This has been suggested and demonstrated by 
the National Bureau of Standards. 21 ’ 22 ). 

USNO GPS Time Service 

Data from the GPS satellites are recovered daily by the USNO and are 
made available through the USNO Time Service Automated Data Service 
(ADS) via standard dial-up telephone line, using a modem and terminal. 
(See Reference 19.) This service was used to obtain more recent data 
than that presented in Reference 19 for a satellite that has had a 
Cesium beam standard operating for some time (SV#9). The data was 
retrieved for a period of 190 days starting on January 1, 1981. The 
results provided by the Time Service are plotted in Figure 9 for both 
the difference between GPS Time and the USNO Master Clock and the 
difference between SV#9's clock and the USNO Master Clock. The fol¬ 
lowing polynomials (three point derived) were removed from the data 
before plotting: 

GPS Time: -35.811 ps - 1.3352X10- 12 s/s X t (8) 

+ (2.81436X10- 1 -/86400)s/s 2 X t 2 

SV#9 Time: 346,428 ns + 3.6651X10- 13 s/s X t (9) 

+ (6.04051X10- 16 /86400) s/s 2 X t 2 
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where t is in seconds since 1 January. These coefficients are equiva¬ 
lent to drift values of: 

GPS Time: Af/f = -1.3352X10- 12 

D = 5.62872X10- 1 Vday 

SV#9 Time: Af/f = 3.6651X10- 13 

D = 1.2081X10- lf, /day 

It is evident from these plots that the satellite's clock is better 
than the GPS clock. This should be expected since the GPS clock is 
much older than the satellite's clock. The fact is that both clocks 
are exhibiting normal "flicker" characteristics. The anomalous 
results that occurred around day 130 are due to transient conditions 
in the GPS system after a "Master" receiver failure. Time in the 
master GPS clock was reinitialized. 23 

The results of Figure 9 are consistent with the results presented in 
Reference 19 for a previous period of time. 

TIME TRANSFER APPLICATIONS 

The Time Transfer System can be employed in a variety of applications. 
As a stand-alone system it can provide an absolute time reference for 
users within GPS. By using the data provided by USNO's Time Services, 
GPS Time (or any of the SV times) can be translated to UTC. More 
stable timing can be achieved by operating the TTS with an external 
Cesium or Rubidium standard to bridge periods of nonvisibility to 
satellites in the current GPS system. Intermittent accurate time 
transfer can be achieved with the optional internal crystal oscilla¬ 
tor, with accuracies on the order of microseconds during periods of 
nonvisibi1ity. 

The TTS can also be used as a calibration device to provide time 
alignment of other standards in the user's timing network. 

For a timing network in which only relative time is required, the 
so-called "common mode-common view" technique of time transfer can be 
employed to provide even better accuracy. 21 In this mode, a highly 
stable TTS is used as the master clock (such as the one at USNO) and 
another TTS at a remote location will be simultaneously scheduled to 
track an identical satellite that is visible from both TTS's. When 
the time offsets obtained from these two TTS's are compared, better 
(relative) accuracy will be achieved due to the cancellation or reduc¬ 
tion of common sources of error, e.g., satellite clock and ephemeris 
error, and some of the atmospheric time delay error. 
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As an example, Figure 10 shows the times that two TTS's located in 
Washington, D.C. and Paris, France may both see a particular satel¬ 
lite. Note that, even with the six-satellite constellation, the daily 
common view period can be as much as 15 hours. 

This technique is similar to that employed in TV line-10 transfers, 
where simultaneous, common view measurements against a stable trans¬ 
mitter yield measurements with ten-nanosecond uncertainty. Intercon¬ 
tinental time transfer at ten nanoseconds should be possible with GPS 
TTS's. 

FUTURE CONSIDERATIONS 

In the near future, the TTS 502 will be available in a portable config¬ 
uration. The receiver/processor chassis will be packaged as a portable 
unit. The preamplifier and antenna are already quite portable. Port¬ 
able terminals are also available on the market or may already be 
available at remote sites. And the TTS does not need batteries . It 
can be plugged into any 115 VAC wall socket. Initialization parameters 
can be stored in nonvolatile memory (or PROM) at a laboratory or depot 
site, and the TTS can be shipped unattended to a remote site as a 
calibration device. The only starting parameter that is needed is an 
approximate time-of-day and day-of-year, which could conceivably be 
entered with other means besides a terminal (such as a set of thumb¬ 
wheels, a start button, and an LED readout), eliminating the need for a 
terminal. 

As the number of TTS's increase, they will become smaller than "Flying 
Clocks," and competitive in price. They are already lighter (no 
batteries), and much less expensive to maintain and transport (again, 
no batteries). 

As GPS matures and more satellites become available, it is also con¬ 
ceivable that the TTS's will also replace frequency standards in the 
field. Over the short term they are not quite as accurate, but over 
the long term they will be nearly as accurate as UTC itself (±100 
nanoseconds or less). And, they will never need calibrating . As with 
the flying clocks, the TTS will also eventually become competitive in 
price with accurate frequency standards. 
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TABLE I 

TIME TRANSFER ERROR BUDGET 


PHASE I GPS SPECIFIED OCS SPECIFIED 



ONE SIGMA ERROR BUDGET 12 
(nanoseconds) 

ONE SIGMA ERROR BUDGET 
(nanoseconds) 

SV GROUP DELAY 

AND CLOCK 

9 (for 2 hrs) 

25.5-108 (for 24 hrs) 

20* 

SV EPHEMERIS 

12 (for 24 hrs) 


IONOSPHERIC/ 

TROPOSPHERIC 

DELAY/MULTIPATH 

5-40** 

5-40** 

RECEIVER NOISE 
(RAW/SMOOTHED) 

6.3/1.0 

6. 3/1.0 

PSEUDORANGE 

QUANTIZATION 

(RAW/SMOOTHED) 

5.8/0.9 

5.8/0.9 

USER LOCATION 
ESTIMATION AND 
RECEIVER BIAS 

5-15 

5-15 

TOTAL (RSS) 
(RAW/SMOOTHED) 

(18-117)/(17-117)*** 
(18-52)/(17-51)**** 

(23-50)/(21-47) 


* BETWEEN SUCCESSIVE UPLOADS 13 

** ELEVATION ANGLE, LATITUDE AND TIME OF DAY DEPENDENT 

*** RUBIDIUM FREQUENCY STANDARD IN SATELLITE 

**** CESIUM FREQUENCY STANDARD IN SATELLITE 
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TIME __ 


EPOCH TRANSMITTED 
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SATELLITE 

TIME _ L 


I— EPOCH RECEIVED 
j AT STATION 


: SATELLITE TIME AT EPOCH TRANSMISSION 


GPS TIME AT EPOCH TRANSMISSION 


SATELLITE CLOCK ERROR AT EPOCH TRANSMISSION 


USER TIME AT EPOCH ARRIVAL 


GPS TIME AT EPOCH ARRIVAL 


: USER CLOCK ERROR AT EPOCH ARRIVAL 


= USER-MEASURED PSEUDORANGE 


FIGURE 3 TIMING RELATIONSHIPS 
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FIGURE 5 TTS-502 TIME SOURCE OPERATION MODES 











FIGURE 6 TIME TRANSFER RECEIVER/PROCESSOR MODEL 5026 BLOCK DIAGRAM 
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FIGURE 7 MEAN IONOSPHERIC DELAY AND ENVELOPE OF DELAY VARIATION VS. TIME 
OF DAY DURING -MARCH,1958- SATELLITE AT ZENITH f=1.6 GHz 
(FROM REFERENCE 16) 
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-100 NANOSECONDS 
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O = GPS TTU (STI SUNNYVALE) SV #8 

A = ops rru (sti Sunnyvale) sv #6 

-1-1-1-1-—i-1-1_i_i 

14 11/15 11/16 11/17 11/18 11/19 11/20 11/21 11/22 

DATE (UTC) 

FIGURE 8 INTIAL TIME TRANSFER RESULTS 
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QUESTIONS AND ANSWERS 


MR. KELLOGG, Lockheed 

In collecting the data and evaluating it, I noticed you have gone 
through the U.S. Naval Observatory time comparison with UTC; is 
that true or that is just a possibility? 

MR. HUA: 

That's true. 

MR. KELLOGG: 

Do you have any data which would permit evaluating whether we 
should have great confidence in the relativity corrections which 
have been built in to the standard on board the satellite? 

MR. HUA: 

I do not have any answer. I do not know much about that to answer 
your question about relativity. 

MR. ALLAN: 

I think I can answer that, and the corrections, I believe, are 
correct, and I think you can have great confidence in those. 

MR. KELLOGG: 

Thank you. 
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